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foreword 


This report descries the £*•«£.*: jScS“i“ 
of the airworthiness assurance ^ Conducted as the basic task 
quadruplex digital flig , critical pitch-axis functions for 
under NAS2-11853, the e “° r J Variations in redundancy management 
a relaxed static stabi ^alvtioahy ' and considerable simulator testing 
schemes were examined J . ; m at t he Reconf igurable Digital 

Till" CoZol Sys tern" (RDFCS ) Simulator at NASA ^es Research Center. 

The intent of this proiect was ^r^Ml^y 
associated assurance issues f static margins and fly -by-wire 
augmentation accommodating nega _ assurance approach that closely 
primary flight control. An m eg in a manne r exemplifying key 
couples testing with analysis was ^ ’ clrcular 25.1309-01. Both the 

aspects "“port „ ere developed with the view toward its 
investigations and this rep 


use for tutorial purposes. 
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EXECUTIVE SUMMARY 


A double fail-operational digital flight control system (DFCS) as shown 
in Figure E-l was designed, analyzed, implemented, and validated relati 
to sjste„ fault tolerance and a subset of pitch-axis control function. 
The system- level fault tolerance design, which from the outset w 
constrained by the Reconf igurable Digital Flight Control System (RDFCS) 
configuration at NASA Ames (Reference 1), was verified usi g 
predicate/transition network simulation tool developed by the Lock ^- 
Georgia Company (Reference 2). The Ada (tm) programming language was 

used g for software design, but the actual demonstration flight softwar 
was rendered in AED (Algol Extended for Design) as necessary for use 

the RDFCS . 

The demonstration at NASA Ames involved modifications to the 
DFCS and system simulator as portrayed m Figure E-2 Basical y, 
dual- dual Architecture was transferred into a quad, cuplex archx ecture 
through strictly software changes to extend fault tolerance for full-t 
flight criticality. Although the resultant implementation ^J^-optim 

from a real-time standpoint, it did realize the verified design. This 

served to illustrate the propagation and confirmation of consis y 

throughout the development process and to permit the demons ra 
real-time validation testing methods. 


SENSOR 
SET A 



Figure E-l. Quadruplex DFCS Architecture 
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In all, the simulator modifications or enhancements were considerable It 
was necessary to alter software in the PDP-11/60 to add relaxed static 
stability flight cases and new sensor signal outputs, and to add a real- 
time execution monitor The new sensor signals in turn ca.lod for changes 
to the modular digital interface conversion unit (MDICU) program. Flight 
software states used by the monitor were obtained through the addition of 
instrumentation software in the PDP-11/04. Since the PDP- 11/04 
instrumentation response was insufficient for some purposes one rekl- 
time execution monitor was programmed in one of the four flight computer 
channels to monitor - the other three processors. 

Finally, correspondence was established between design verification 
simulation of the fault- tolerant architecture design and real-time system 
results of the quadruplex DFCS . Essentially the same test cases and 
instrumentation parameters were used in both cases. Observability was 
superior in the case of the design verification simulation for in some 
cases, implementation aspects increased the instrumentation task The 
latter proved quite worthwhile in providing more confidence by confirming 
the executional correctness of low-level mechanization derails. 



Figure E-2. RDFCS Facility Set-Up 
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1.0 INTRODUCTION 


With the advent of full-time critical control functions, such as 
augmented fly-by-wire (AFBW) primary flight control systems, considers y 
more effort must be directed toward ensuring and confirming their safety 
than would be necessary for flight-phase critical functions such as 
autoland. As illustrated in this report, such effort involves the 
definition of fault- tolerant system architectures and the application^ 
a suite of assurance tools to confirm system airworthiness. Since 
virtually all flight control systems are now implemented digita y, means 
™st be ployed ?o cope with greater inherent complexity than present in 
comparable analog mechanizations. The addition of fault tolerance 
mechanisms for achieving adequate system reliability, moreover, compounds 
this complexity problem. 

At a system architecture level, the fault- tolerant system differences 
between analog and digital mechanization are only beginning to be ve y 
notable. But to attain adequate confidence levels m system 

airworthiness, lower levels of digital mechanization must be examined^ 

This is where assurance methods and tools are essential^ Much of the 
focus of much of this report, then, is directed toward the dependable 
attainment of the higher assurance levels stipulated in the JAA Advisory 
Circular 25.1309-1 (Reference 5). The approach taken here is the use of 
an integrated assurance methodology wherein the tools and methods are 
mutually reinforcing. Such an approach has previously been demonstrated 
at the system level (Reference 6). 

Unfortunately, the requisite assurance methods with very appreciable 
demands placed on them, have yet to be fully developed and cooperatively 
demonstrated. Overall, assurance levels of 10 _ exp. -9 or less 

unreliability remain to be convincingly demonstrated in typical practice. 
This investigation offers some promising approaches to such concerns y 
way of an assurance driven methodology applied from initial design 
through real-time system simulation. 


1.1 Assessment Rationale 


Several dimensions of assurance method integration should be acknowledged 
in a comprehensive assessment process: 

o Reliability, failure effects, and functional performance assessment 
methods 

o Analysis, test, and inspection types of the above methods 

o Mutually supportive incorporation of all of the above in an 
assurance driven system development methodology. 
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Figure 1 depicts a central notion in the integrated assurance methodology 
used in the subject investigation. Basically, analysis is applied on a 
global scale to models or abstractions of the evolving DFCS 
configuration. Accordingly, analysis is the dominant assurance approach 
during the early stages of development, when only limited descriptions of 
the design are available. At that time inspections or walkthroughs are 
valuable as well, e.g., a review of the fault conditions applied in 
exercising the predicate/transition network simulation. Inspection comes 
into play, moreover, any time engineering judgment is exercised in 
determining the significance or validity of development process results. 


SOLUTION OOMAlN 



Figure 1. Complementarity of Assurance Methods 
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mechanized, 
limited, so only 
investigated. This 
complementarity of 


Since testing is usually considered to apply only on actual 
Implementations , It takes place only after the test article has been 
But the scope of practical test examination is necessarily 
a small subset of possible test cases can be 

situation gives rise to the major aspect of the 
elements of an integrated methodology. Primarily, 
testing seeks to examine: the validity of selected analytical results; 

facets not amenable to analysis; assumptions underlying analyses; and 
operator -in- the - loop performance. Basically, testing is concrete, hig 
fidelity, and readily convincing, but of it is lacking because of its 
inherently limited scope. Judicious test case selection is therefore 
vital in maximizing the assurances obtained through testing, but testing 
alone cannot provide adequate assurances. 

Analysis, on the other hand, is abstract, idealized, and general, but 
very dependent upon proper formulation and interpretation. Analysis, 
moreover, is essential to effective testing. Various levels of analysis 
are involved in maximizing the conclusiveness of testing, as through the 
coincident, multilevel testing approach shown in Figure 2. As each stage 
of development proceeds, associated analyses yield test case definitions 
that can affirm that the ultimate implementation has remained m accor 
with prior design decisions. The fact that the various test cases can be 
applied coincidentally indicates another dimension of integrated 
assurance, one that can greatly extend validation process confidence and 
productivity . 



Figure 2. Basis of Multilevel Testing 
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1.2 Relevance to Other Tasks 


This task is closely related to the N-verslon software fault 

tolerance task performed under the same contract (Reference 7) 
Basically, the same quadruplex DFCS design was used in both cases. Here, 
the executive software was implemented in AED, and system redundancy- 
management issues were examined in a real-time system sinulator. The In- 
version investigation focused mainly on Ada implemented applications 
software and its fault tolerance; a non-realtime test harness that 

supplanted the executive software was used so that the four channels of 
applications software could be run logically in parallel. Had the 
quadruplex DFCS been implemented in Ada, it would have been relatively 
easy to add the N-version software to it. As it turned out, the 

compatibility of the two task products proved useful for tutorial 

purposes . 

Additionally, the task on analytical sensor redundancy was quite closely 
related to the subject one (Reference 8). Specifically, the analytical 
redundancy algorithms were added to the quadruplex DFCS software for the 
pitch stability augmentation sensors. In summary, these three tasks 
addressed computer hardware faults, sensor hardware faults and DFCS 
applications software faults, all within the context and particular 
design constraints of the quadruplex DFCS architecture in this report 
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2.0 BACKGROUND 


There is an appreciable difference between the airworthiness assurances 
demanded of a full-time critical function, which is always required for 
flight and a flight-phase critical function, which may experience _ 
very limited use. In particular, a primary flight control system is 
absolutely necessary at all times for safe flight, whereas a Category 
a auto land is seldom used under actual Category Ilia weather minimum^ 
While safety of a critical function must be assured in both cases, the 
^sk in the former instance is far greater because of exposure time and 
severe limitations on alternatives. When such functions are mechanized 
digitally, there is presently concern over the capacity to ensure 
airworthiness. As a consequence, this investigation has sought 
demonstrate the associated technology and its application m a 
representative DFCS development problem for a pitch-axis AFBW. 


2 . 1 Terminology 

In this report, the term ASSURANCE TECHNOLOGY is used in a very general 
sense to apply to all methods and activities for achieving or confirming 
the acceptability of a system. Primary emphasis, moreover, applies to 
property of AIRWORTHINESS, or the assured safety of the system/vehicle. 
Those system functions whose proper operation is in geneva necessary or 
the safe operation of the aircraft are designated as CRITICAL per 1AA AC 
25.1329-01 (Reference 1). Functions that can noticeably detenora e, u 
not preclude, the capacity for safe operation of the aircraft, are ca e 
ESSENTIAL. 

CERTIFICATION refers to the formal process whereby the FAA authorizes 
deployment of an aircraft or system in response to evidence 
substantiating that each is indeed airworthy. Desirably, this process is 
supported with methods and tools over the development cycle that 
facilitate or ensure the conclusiveness of the evidence. The DF 
development cycle culminates with system VALIDATION, or confirmation that 
user requirements have been satisfied. Since these necessarily encompass 
system airworthiness, major emphasis in this report is placed on 
validating requisite fault survivability. 

Of course the assurance process is a cumulative one that endeavors to 
attain increasingly convincing evidence of aircraft/system 

Prior to product validation then, there are a sene n . g 

q tens wherein compliance with various ievej_i> F 

demonstrated Of particular note here is system design verification 
because as the first critical step in assuring the emerging system, it 
establishes the caliber and credibility of the overall assurance process. 
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In the earlier stages of system development, for example, oorsiderable 
reliance is placed on analysis to confirm acceptability on a global or 
general basis. As the system is implemented, greater reliance is placed 
on testing particular aspects of the product. But properly, such testing 
derives from and reinforces the prior analyses (e.g., see Reference 6). 
In summary , note that verification ensures that a system is being 
constructed right, or per specification, and that validatior confirms 
that the "right system," or what the user wants, is being constructed 
(Reference 9) . 


2.2 FAA Regulatory Needs 

Prior to the introduction of DFCS s, technical leadership within the FAA 
recognized and addressed the attendant challenges in the mid-1970s 
(Reference 10), as evident by the number of DFCSs certificated to date. 
These have limited function criticality, however, and with the current 
prospects for substantial or full-time reliance on critical DFCS 
functions, the FAA has again updated its digital technology agenda (see 
Reference 11). Basically, the FAA perceives a need within Its Regulatory 
staff to become familiarized with the nature and assurance challenges of 
the emerging critical systems. 

Particular attention has been directed toward stability augmentation 
systems (SASs) and fly-by-wire (FBW) systems as soon to appear on 
commercial transports . Aside from function criticality per se, the issue 
of flying qualities under faults must be confronted regarding minimum 
safety over admissible flight profiles. This opens new areas c f concern 
for the FAA, ones that ought to be illustrated on a demonstrate!* program 
of a tutorial nature. 


2. 3 General Problem 

From the reliability standpoint, the analytical resolution demanded for 
critical functions is a problem in itself for digital flight systems, and 
the cumulative degradation of flying qualities under multiple faults must 
be factored into the analysis. Other related aspects of the problem 
include dissimilar redundancy, back-up systems or instruments, fault 
transients recovery, and pilot workload limits. Interdisciplinary in 
nature, the overall problem is new as far as the certification of civil 
transports is concerned, so there is a serious and immediate need to 
formulate a unified assessment approach. 


2.4 System Simulator Role 

System simulation with system components, and possibly a pilot, in the 
loop is a vital and central part of flight controls practice, both before 
and after the advent of digital flight controls. To a lesser extent, 
developmental flight simulators have been used as well, especially for 
stability or control augmented military vehicles. Some of the work 
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undertaken on this project is intended to develop “"^“^ccppSu 
utilization of system simulation, but owing to the lock of an accep 
pilot interface in the RDFCS facility, a full simulator assessment of the 
quadruplex DFCS could not be demonstrated. Hence, this report o y 

undertakes to describe the contributions of the pilot-in-the- oop ro e 
flight simulators. 

In the case of both system and flight simulators, the fidelity provided 
ly ^tem elements in the real-time loop is especially 1-portant In the 
case of digital systems because the inherent extra phase lag due to da 
holds and transport lags tends to seriously degrade system performance^ 
Add to this the non-minimum phase characteristics of human Pilots, 
there° is a suitable basis for delineating of minimum safe flying 
qualities. Since the associated DFCS control law analysis may not 
acknowledge these effects, the simulators become especially vital 

digital systems . 

Since the newer DFCSs are accompanied by electronic displays and 
cockpit innovations, the pilot- in- the - loop performance has new aspects to 
be assessed For example, the reversion to back-up electromechanica 
attitude displays under degraded flying qualities or stressful 
operational conditions may well alter what constitutes minimum safe 
flying qualities. Ultimately, such questions may not be difficult to 
resolve, but they do remain to be addressed coherently. 

2.5 Assurance Technology 

A rather broad definition of assurance technology was given in Section 
2 2 Here it suffices to note that assurance features can be designed 
into a DFCS in a way that greatly facilitates the conduct an 
conclusiveness of the assurance process; this is an old th «“ |*at is 
particularly apt for fault- tolerant systems (see References 12 and 13). 
Since the testing reported here is for system validation especially, 
under simulated faults, the overall assessment theme is to in ^ s ^ate how 
accountability is propagated into the validation stage and what this 
stage contributes to the process. 


2.6 Project Approach 

In the interest of focusing the resources avaiiable for this task an 
existing; quadruplex pitch axis DFCS installed m the RDFCS facility was 
used as a test article. Developed under a Lockheed- funded project this 
configuration resulted primarily from flight software changes to the 
basic single fail-operational, dual-dual RDFCS to obtain a double fail- 
operational systems. Although some constraints were imposed, the 
resulting system is quite representative of conventional quadruplex 
systems Furthermore, since it was originally developed to demonstrate a 
rigorous system/software design methodology (see Reference 14) , it was 
especially^ well-suited for use in an overall assurance assessment 

example . 
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3.0 OBJECTIVES 


This quadruplex DFCS assessment investigation was intended to illustrate 
a critical DFCS assurance process, with focus on airworthiness 
certification topics. The investigation was largely motivated y 
prospects for certification technology tutorials. The methods illustrated 
were P to be technically sound, pragmatically constructive, and where 
possible innovative relative to the state of practice. The methods 
employed! however, are not necessarily held to be the best or the o y 
effective ones for critical DFCS use. 


3 . 1 Goal 

This work is intended to provide a plausible and representative example 
S how to assure the airworthiness of full-time flight-critical digital 
flisht systems in the near future. although addressed at a scaled-down 
level the double fail-operational quadruplex DFCS 
representative of near-term certification challenges, as for SAS 

systems Se emphasis, however, is on the integrated use of assurance 

methods automated tools for system simulator testing and analytic 
test case definition, hopefully, the results obtained will foster a 
meaningful advance in the state of certification practice, with 
particular benefits accruing to the productivity and conclusiveness of 
validation testing. 


3.2 Specific Objectives 


The overall objective of this project has been the establishment of 
airworthiness technology readiness for fault- tolerant system 
architectures for full-time critical functions. Aside from the 
development and demonstration of the relevant technology attainment of 
this objective is crucially dependent on the dissemination of results 
both in report form and in tutorial workshops. Realization of the overall 
objective, moreover, has been predicated on the following elemen 

obj ectives : 

o Quantitative analytical comparison of basic DFCS redundancy levels 
relative to system reliability 


o Quantitative analytical comparison of. alternative quadruplex 
configurations relative to system reliability 

o Critique of critical AFBW mechanization in terms of fault 
survivability 


O System simulator demonstration' of basic quadruplex DFCS fault 
survivability, in part using automated test methods. 


preceding page blank not filmed 


3 . 3 Scope 


As noted in Section 2.4, this investigation of augmented flying qualities 
was conducted without an acceptable pilot interface. This resulted from 
RDFCS facility limitations and funding level realities. Also, the 
quadruplex DFCS was implemented almost solely through software 
modifications, so while functionally representative, certain aspects 
usually implemented in hardware were rendered in software. Only pitch 
axis flight control functions were incorporated in the DFCS, but these 
served to illustrate the newer type critical functions. In alL, a balance 
was sought between available resources and realizable results, and where 
project economies were necessary, this report has attempted to address 
and elucidate the associated technical issues and consequences. 


3.4 Expectations 

Since this effort has focused primarily on system architectures, there 
remains a need to explore complementary aspects of minimum safe stability 
augmentation functions using pilot- in- the - loop flight simulation. The 
need encompasses both methods and criteria, as well as a means to 
incorporate the associated results into the overall assurance process. Of 
course flight simulation entails a high fidelity flight station with 
electronic displays and appropriate controllers. It is therefore 
projected that this type undertaking will soon be pursued by a 
multidisciplinary team in the context of commercial transport 
applications . 

In the farther term, as fault- tolerant architectures become more 
sophisticated, the role of the system simulator is expected to be 
diminished by a more general and powerful system development facility 
known as a rapid prototyping environment. Such a facility places greater 
emphasis on assurance activities on the front-end of the development 
cycle, and subsequently propagated accountability. It is therefore 
projected that such facilities and their enabling methods and tools will 
evolve over the next decade to become standard type installations within 
the airframe business. 
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4 . 0 TASK RESULTS 


With existing RDFCS constraints in mind, a representative double fail- 
operational DFCS architecture was defined from among a set of related 
candidates. The redundancy management coordination of this design was 
verified through predicate/transition network simulation, and the high- 
level software design was then represented in nested control graphs. The 
actual flight code was rendered in AED, beginning with an austere real- 
time executive, and loaded into the Collins CAPS -6 flight computers at 
NASA Ames. Cross-channel coordination was effected through respective 
channel control states broadcasted over corresponding serial digital 
buses. The quadruplex DFCS was then tested under various simulated fault 
and anomaly conditions using real-time software execution monitors to 
resolve low-level system management events. 

RSS flight cases were installed in the PDP-11/60 flight simulation at 
NASA Ames, and validated using previously defined airplane root solutions 
and time history check cases. New AFBW sensor outputs were ported from 
the PDP-11/60, through the MDICU, to the flight computers. Also, new mode 
and fault logic signals were assigned on the logic discrete switch panel 
on the simulator pallet. Lastly, the pitch-axis manual control stick 
inputs were introduced into the flight computers from a hand controller. 

Hence, it was possible to assess flying qualities degradation through 
real-time closed-loop system simulation, with or without an operator in 
the loop. Unfortunately, the manual flying qualities assessment was 
hampered by the poor quality of pilot interface available, but the 
characteristics of the free or unaugmented airplane yielded such severe 
or noticeable degradation under some sensor faults that the interface was 
actually of some use. 


4.1 System Definitions 

System definition evolved per the development products noted in Figure 3, 
which depicts mechanization increments along the downward path on the 
left, and assurance milestones along the upward path on the right. 
Further detail on the development activities are presented in Table 1 
within the framework of the typical stages of development. Certain of 
the aforementioned development products are illustrated later in this 
report. The intent here is to exemplify key steps, corresponding to pro- 
gressive system definitions, that should lead to a certifiable DFCS. 
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Figure 3. Digital Flight System Life Cycle 
















Table 1. Development Phase Activities and Products 


■ 

I’HASE 

PURPOSE 

INPUT 

PROC ES‘ 

MECHANIZATION 

5 

ASSURANCE 

DEVELOPMENT 

PRODUCT 

SYSTEM STATUS 



CONCEPTUAL ' 
t 

PROVIDE FOR 
JSER NEEDS” 

MISSION REQUIREMENTS 

FORMULATE SYSTEM 
REQUIREMENTS 
EXPLORE DESIGN 
SOLUTIONS 

VALIDATE REQUIREMENTS 
ANALYZE DESIGN 
SOLUTIONS 

SYSTEM REQUIREMENTS 
SYSTEM CONCEPTS 

FUNCTIONAL 

ARCHITECTURE 

"FEASIBLE 

DESIGN 

SOLUTION” 


DEFINITION 

1 

i 

•DESIGN FOR 
USER NEEDS” 

AIRWORTHINESS RE- 
QUIREMENTS, SYSTEM 

requirements, 

SYSTEM CONCEPTS 

FORMULATE SYSTEM 
SPECIFICATION RE 
FINE SYSTEM 
CONCEPTS 

VERIFY SPECIFICATIONS 
VALIDATE SYSTEMS 
CONCEPTS 

SYSTEM SPECIFICATION 
CONCEPTUAL SYSTEM 
DESIGN 

VALIDATED 

CONCEPTUAL 

DESIGN 

"ACCEPTABLE 

DESIGN 

SOLUTION” 


_L 

i 

ANALYSIS 

•'DESIGN 
SYSTEM TO 
SPECIFICA- 
TION” 

SYSTEM SPECIFICATION 

DESIGN SYSTEM 
STRUCTURE, DESIGN 
CONTROL LAWS 

VERIFY SOFTWARE 
SPECIFICATION, VERIFY 
SYSTEM STRUCTURE, 
VERIFY CONTROL LAWS 

SYSTEM DESIGN 
SOFTWARE SPECIFICA- 
TIONS, HARDWARE 
SPECIFICATIONS 

VERIFIED SYSTEM 
STRUCTURE 
"SUPERIOR 
DESIGN SOLU- 
TION” 


DESIGN 

"DESIGN 
SOFTWARE TO 
SPECIFICA 
TION” 

SOFTWARE 

SPECIFICATION 

DESIGN SOFTWARE 
STRUCTURE, DEFINE 
SOFTWARE COMPO- 
NENTS 

VERIFY SOFTWARE 
DESIGN. VERIFY UNIT 
SPECIFICATIONS 

SOFTWARE DESIGN 
PROGRAM UNIT 
SPECIFICATIONS 

VERIFIED BASE 
LINE DESIGN 
“COMPREHENSIVE 
DESIGN DEFINI- 
TION” 


CODING 

AND 

CHECKOUT 

"IMPLEMENT 
SOFTWARE 
TO SPECI 
F 1 C A T IONS'* 

UNIT SPECIFICATIONS 

IMPLEMENT 
PROCRAM UNITS 

CHECK/OE-BUG 
UNITS, VERIFY 
PROGRAM UNITS 

SOFTWARE 

IMPLEMENTATION 

BASELINE SYSTEM 
CONFIGURATION 
"COMPREHENSIVE 
SYSTEM DEFINI- 
TION” 


_ 

INTEGRA 

LION 

"CONSTRUCT 
SYSTEM WITH 
HARDWARE / 
SOFTWARE 
COMPONENTS” 

VERIFIED STRUCTURE 
AND COMPONENTS 

ASSEMBLE/DEVELOP 

SYSTEM 

10ENTIFY/RECTIFY 

INCONSISTENCIES 

SYSTEM 

IMPLEMENTATION 

DEVELOPMENTAL 

SYSTEM 

- 

DEVELOP 
LIE N T TEST 

"TEST TO 
SPECIFICA 
TION RE- 
QUIREMENTS” 

SYSTEM SPECIFICATIONS 

i DEVELOP SYSTEM 
OPTIMIZE PERFORM- 
ANCE 

IDENTIFY /RECTIFY 
DEFICIENCIES 
VERIFY PERFORM- 
ANCE 

VERIFIED 

IMPLEMENTATION 

VERIFIED 

SYSTEM 

VALIDATION 

"TEST FOR 

REQUIRE 

MFNTS 

COMPLIANCE” 

SYSTEM REQUIREMENTS 

MODIFY SYSTEM IF 
NECESSARY 

CONFIRM 

ACCEPTABILITY 

PROVISIONAL 

CONFIGURATION 

VALIDATED 

SYSTEM 


L TR TIFIC A 
HON 

"DEMON 
STRATE 
AIR WORTH 
INESS COM- 
PLI ANCF” 

AIRWORTHINESS RE- 
QUIREMENTS 
CFRTIFICAT ION PLAN 

MODIFY SYSTEM IF 
NECESSARY 

.L 

CONFIRM 

AIRWORTHINESS 

PRODUCTION 

CONFIGURATION 

CERTIFICATED 

SYSTEM 
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Broadly, design definitions usually address either sysi 
architecture. The former centers on control laws, and x 
into a detailing of system/software structure. Wit 
structure of digital mechanizations, it is partii 
explicitly describe the organization of the flight softv 
aspects of system definition are discussed further in 1 
sections prior to presenting application examples, 
centrality to re 1 iable/fault - tolerant DFCSs, partici 
placed on system/software architecture. Hence’ the desi 
Figure 4 have been illustrated through a sequence of e> 
stages. 
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he following sub- 
Because of its 
lar emphasis is 
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ample development 


“CONSISTENCY 



Figure 4. Architecture Design Tasks 
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4.1.1 Quadruplex System Description 

Most DFCSs to date have essentially been digitized versions of previous 
analog mechanizations. These DFCSs have been characterized by: 
conventional system architectures based upon parallel replication; 
frequency domain derived control laws mapped into difference equations, 
and multirate foreground executive programs to periodically call 
appropriate applications software for selected control functions. In 
general, systems have been dedicated strictly to control functions, 
thereby avoiding potentially debilitating software anomalies resulting 
from interference by other software functions. 

Parallel channels, each with virtually the same software, have only 
recently yielded to dissimilar processors or software to reduce the 
possibilities for coincident or generic design faults. Similarly, 
floating-point arithmetic processors are beginning to replace fixed-point 
processors; this change obviates the need for scaling variables, another 
carry-over from analog computer practice. Higher-order programming 
languages are becoming prevalent for quality and cost reasons, and Ada 
will likely soon dominate software on commercial aircraft. Multiplex 
(MUX) data buses are now predominant over point-to-point buses for 
broader and more general usage of resources. 


4. 1.1.1 Pitch Augmentation Function 

To pose a full-time criticality problem, a relaxed static stability 
transport airplane was defined with a negative stability margin and a 
fly-by-wire primary flight control system. The associated control law 
depicted in Figure 5 is employed in each of four computational channels, 
as indicated by the quad input voters. Pilot commands are applied through 
control stick inputs; short-period damping is provided by actual, not 
derived, pitch rate; and angle-of -attack is used to control pitch-axis 
divergence associated with RSS. Special signal processing includes 
control stick deadbands and pilot/copilot stick blending, left/right 
angle-of-attack averaging, and command limiting. 

Because control surface effectiveness varies over the flight profile, 
certain DFCS gains must do likewise. This facet of design is referred to 
as gain scheduling, and true airspeed is often used to schedule control 
law parameters. In this investigation, six point simulation flight cases 
were employed, so Table 2 presents their associated sensor feedback 
gains. Note that the gains are generally less at higher speeds because 
control surface effectiveness tends to increase with speed. 
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Figure 5. Augmented Fly-by-Wire Control Laws 


Table 2. Stability Augmentation Gain Scheduling 


FLIGHT 

CASE 

TRUE 

AIRSPEED 

(fps) 

K a 

(deg. /deg. ) 

K e 

(deg /deg. per sec.) 

AlRSS 

283.7 

1 .00 

o 

O 

C13RSS 

910.7 

0.73 

0.10 

C15RSS 

442.2 

1.00 

0.40 

D2RSS 

487.1 

1.00 

0.33 

E3RSS 

265.7 

1.00 

0.80 

F6RSS 

224.1 

1.00 

o 

v_n 

O 
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4. 1.1.2 Basic System Architecture 


The first DFCS architectures introduced were rather conventional in that 
they largely reflected prior analog configurations, at least at the block 
diagram level. These employed parallel, replicated channels wherein 
sensors fan-in to processors, which in turn fan-out to effectors or 
displays. Figure 6 presents an expansion of such an architecture for the 
pitch-axis AFBW function. Except for cross-channel communication, all 
signal paths are dedicated analog paths, and fan-in is minimized by 
having one sensor set applied directly to each computational channel. 
Each channel then broadcasts its received inputs to the other three. 
Other architectural options are described and critiqued later. 

The top-level primary flight control system (AFBW) requirements are 
assumed to be MIL-F-9490D operational states (Reference 15) . Because 
these have well defined meaning that encompasses both airplane flying 
qualities and system safety in terms of redundancy margins. Operational 
State 1 denotes normal system status and Level 1 or good flying 
qualities; State 2 admits some deterioration in safety margins and Level 
2 or somewhat degraded flying qualities; State 3 indicates marginal 
safety margins and flying qualities (Level 3) ; and State 4 or worse 
designates unsafe componentry and/or flying qualities. Knowledge of 
flying qualities degradation under successive component failures enables 
the operational state logic to be viewed from strictly an architectural 
point of view. The system design task then focuses on channel - level logic 
definition to effectuate the system-level logic. 

Figure 7 represents the top-level DFCS channel logic design, where the 
names within the circles correspond to particular states that associated 
logic variables can assume. These variables denote states or sub- states 
of the channel. The names appearing on the arcs of the state transition 
graphs designate independent logic events such as pilot mode selection, a 
timer interrupt, or a component failure. Such events in turn may effect 
changes in the channel states per se, which must reflect the state of the 
system. Note that the transition graphs are nested to reduce 
complexity; the lower- level graphs, moreover, capture sub -state 
information . 
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Figure 7. Channel Logic Transition Graph 
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In the Gate Sub-state of the Cycling State, for example, each channel 
develops its view of system status based on control state information for 
each of the four channels. This type of consensus is one of the major 
determinants in calculating the operational state of the system. In all, 
the implementation of this design obviously necessitates an appreciable 
expansion of the logic in the flight code. First, however, it is 
necessary to examine the system level coordination lo£ ic meeting the 
timing constraints in Table 3. 

System synchronization logic with a discrete time se imposed is 
captured in Figure 8, which is called a predicate/trans i tion network 
(Reference 2). This view represents only one channel, but all four are 
the same for the subject architecture. Here the same logic nomenclature 
is retained where applicable, and some new logic variables are added, 
the logic names appear in the rounded boxes, which are called "places" in 
the network. At any given time, the collective values of all places 
constitute the state of the system modeled. To examine and verify the 
correc tiaess of all possible state sequences, the network's operation must 
be simulated using a computer program. Properly accompl ished , such a 
simulation, under both faulted and fault-free conditions, verifies the 
system logic design. 




s, 


Table 3. Cycling State Loop Timing 




GLOBAL 

FOREGROUND 

BACKGROUND 

GATE 

SYNCH 


0-1 MS 

1 _t fg 

% - 48 

48-49 

49-50 

E— 

RUN 

FALSE 

TRUE 

TRUE 

FALSE 

FALSE 

UJ 

> 

READY 

TRUE 

TRUE 

- 1 

FALSE 

FALSE 

TRUE 


RESET 

TRUE 

| 

FALSE 

FALSE 

FALSE 

FALSE 


o 50 MILLISECOND (MS) COMPUTATIONAL FRAME TIME 
o fg 48 MS 

o TIMER INTERRUPT AT t = 48 MS -> RUN 
° RESET t = 0 
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The simulation is based on the firing of "transitions," as denoted by 
rectangles, which yield new values for the logic variables stored in the 
places. The top half of each transition box describes a predicate whose 
satisfaction by system logic values enables it to be fired. Whenever a 
transition fires, the new logic values described in the bottom half of 
the rectangle are assigned. these values are then reflected in the 
appropriate places, and a new network state produces a new set of 
transition that can be fired. 

This mechanism can be seen more clearly by noting the partial network in 
Figure 9. Here the network captures a design wherein the hardware 
initialization within a channel sets its POWERON to True and its CLEAR 
to False. This arms the top transition, whose firing corresponds to 



Figure 9 . 


Predicate/Transition Network Detail 
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software initialization that sets CLEAR to True among other logic 
variable assignments shown. Referring to Figure 9, note that the event 
of CLEAR be set to True effects the top-level channel state transition 
from DOWN to ADAPTING. At this point, the channel tries to synchronize 
with the other channels, to enter the CYCLING state. 


Network simulation should always yield acceptable system states, and 
should never terminate unless all channels are failed. Determining that 
this is the case is a matter of defining and obtaining correct logic 
operation. In the subject investigation, this was accomplished with one 
exception noted later. Figure 10 illustrates some typical discrete - event 
simulation results for four-way channel synchronization. The pulses at 
the top indicate instances wherein individual channels were forced out of 
synchronization, i.e., the corresponding logic variable RECOVER went 
True. The re-synchronization logic in the network mode t en 
satisfactorily restored synchronization, and the RECOVER was set to False 
as indicated by the end of the pulse in Figure 10. 


Following synchronization design verification which captured time- ase 
hardware/software interaction, the design emphasis shifted to the top- 
level software design with the constraints imposed by the existing RDFCS 
hardware . 
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10. Predicate/Trans ition Network Simulation Output 
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Executive Flight Software Organization 


4 . 1 . 1. 3 

4 - fVip flieht software is hardware 

As with the basic Collins syste . s f nce the AFBW control laws 

interrupt-driven at the given executive software invokes the 

— - - — 

synchronous .double fall-operational manner. 

To achieve this, the cha ""^ de ^f" ^'it^objecUvis of: maintaining 

must be mapped into a software g transition; and minimizing 

consistency in the «y 8t ^; 8 ° f ^”diSy? the control graph in Figure 
the complexity of the softw - level g t r a nsition graph in Figure 7 to 

11 represents a mapping of t P ve s the design logic in a form 

a software control structure tha P complexity per the cyclomatic 

exhibiting only moderate ^ision J^ts , the control graph yields test 

r' e Inp"%eft e ornnd logic assertions that sere later used in verifying 

the implemented code. 
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4.2 Reliability Assessment 


Reliability assessments were directed toward contrasting levels and types 
of redundancy relative to their impact on system reliability for critical 
functions. Table 4 delineates 12 different system architectures that 
were analyzed for critical system function failure on both five- and ten- 
hour missions. The system architecture in Figure 6 actually corresponds 
to Cases 1 and 2 in Table 4, depending upon whether inherent back-up 
capability is invokable . Because of the mode selection switch 
arrangement devised in the RDFCS laboratory, the back-up mode was 
manually selectable. Hence, Figure 12 represents the reliability model 
for Architecture Case 1, the one actually implemented. Note that the 
dependencies and logic embedded in this reliability model do not, 
however, apply to Case 2. 

Cases 1 through 5 are all-up AFBW architectures, which are the primary 
concern here. 6 Cases 1 through 3 meet the critical function reliability 


but the analyses only take into account 
to unreliability. Still, the data are 

Basically, the back-up pitch hold mode 
survivability, partly because it would be 
at a time when it too might well be 
of common components with the basic pitch 


requirements of Reference 1, 
hardware fault contributions 
instructive in several ways . 
offers surprisingly little to 
needed so infrequently, and 
unavailable due to the loss 
SAS. 

Cases 4 and 5 are inadequate because of reduced redundancy levels . Cases 
5 through 7 isolate the reliability properties of straight FBW 

architectures. A contrast of Cases 2 and 6 , for example, discloses that 
the critical pitch SAS function increases the probability of failure y 

about only a third for straight FBW. the straight SAS function is 

isolated in Cases 9 through 12, and it is noteworthy that triplex AOAs 
and computers are inadequate per Case 12. Triplex servos, 

quadruplex sensors are, however, satisfactory. 

Tables 5 and 6 reveal flying qualities degradation as well as system 
failure, because the extent and likelihood of degradation are important 
measures of system acceptability. Cases 6 through 8 have been omitted 

because the straight FBW function does not degrade in stages l 
general fails completely when an appropriate combination of failures have 
occurred. Since stability augmentation degradation is basically sensor 
related, this set of servo - oriented architecture variations are not ful y 
useful in delineating flying qualities trade-offs. 

Certain factors, however, are rather interesting. Cases 11 and 12 show 
only a modest increase in flying qualities degradation for the fully 
triplex architecture, but notable disposition toward system failure. 
This suggests that the triplex computers are a weaker point in the 
configuration 12 than the three AOA pairs. Case 8 m Table + tends to 
reinforce this inference. 
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Table 4. 


CASE 

SYSTEM 

SAS BACK-UP 

1 

Quad AFBW 

Pitch Hold 

2 

Quad AFBW 

None 

3 

Quad AFBW 

None 

4 

Quad AFBW 

None 

5 

Dual -Dual AFBW 

None 

6 

Quad FBW 

N/A 

7 

Quad FBW 

N/A 

8 

Triplex FBW 

N/A 

9 

Quad SAS 

Pitch Hold 

10 

Quad SAS 

None 

11 

Quad SAS 

None 

12 

Triplex SAS 

None 


SERVO SET-UP 


SYSTEM FAILURE 


5 -HR 10-HR 


Quad 

.478 

X 

10 

exp 

-10 

.382 

X 

10 

exp 

-9 

Quad 

.615 

X 

10 

exp 

-10 

.492 

X 

10 

exp 

-9 

Triplex 

.626 

X 

10 

exp 

-10 

. 500 

X 

10 

exp 

-9 

Dual - Dual 

.107 

X 

10 

exp 

-7 

.430 

X 

10 

exp 

-7 

Dual - Dual 

.200 

X 

10 

exp 

-6 

.798 

X 

10 

exp 

-6 

Quad 

.457 

X 

10 

exp 

-10 

.365 

X 

10 

exp 

-9 

Triplex 

.468 

X 

10 

exp 

-10 

.374 

X 

10 

exp 

-9 

Triplex 

.153 

X 

10 

exp 

-6 

.612 

X 

10 

exp 

-6 

Quad 

.478 

X 

10 

exp 

-10 

.382 

X 

10 

exp 

-9 

Quad 

.615 

X 

10 

ex - 

10 

.491 

X 

10 

exp 

-9 

Triplex 

.626 

X 

10 

exp 

-10 

. 500 

X 

10 

exp 

- 9 

Triplex 

.188 

X 

10 

exp 

-6 

. / 5 1 

X 

lO 

exp 

- 6 
























Table 6. Flying Qualities Degradation for a 10-Hour Mission 


CASE 


PROBABILITY OF FLYING QUALITIES LEVEL 


1 

2 

3 

Less than 3 

1 

. 999+ 

. 848 x 10 exp -6 

.250 x 10 exp -14 

.382 x 10 exp - 9 

2 

.999+ 

.848 x 10 exp -6 

0 

.492 x 10 exp -9 

3 

.999+ 

.848 x 10 exp -6 

0 

. 500 x 10 exp -9 

4 

.999+ 

.848 x 10 exp -6 

0 

.430 x 10 exp -7 

5 

.999+ 

.240 x 10 exp -3 

0 

.798 x 10 exp -6 

9 

.999+ 

.819 x 10 exp -6 

.108 x 10 exp -9 

.382 x 10 exp -9 

10 

.999 + 

.848 x 10 exp -6 

0 

.492 x 10 exp -9 

11 

.999+ 

.848 x 10 exp -6 

0 

. 500 x 10 exp - 9 

12 

.999+ 

.883 x 10 exp - 6 

i 

0 

.751 x 10 exp -6 



4.2.1 Additional Quadruplex Architectural Variations 

The foregoing architecture constitutes an older vintage of DECS such as 
those retrofitted on an airplane originally wired for analog systems; 
this was a constraint imposed by the RDFCS architecture, which was 
similar to the L-1011 DFCS . In retrofit type situations, system 
interconnect wiring is usually dedicated point-to-point signal paths, 
with little use of digital MUX buses. Currently, parallel MUX buses are 
in common use, and considerably more complex buses topologies are 
expected for future system. Specifically, bandwidth, damage tolerance, 
and system integration are likely to motivate more divesity among MUX bus 
organizations . 


4.3 Relaxed Static Stability Airplane 

A negative static stability margin was postulated as a requirement for 
this investigation, and the existing flight cases for the NASA Ames RDFCS 
simulation (Reference 17) were altered to yield six RSS flight cases. The 
resultant RSS flight cases were then analyzed to determine the pitch axis 
dynamic behavior, and a non-realtime simulation was developed and checked 
against the predicted pitch-axis dynamics for the free, or unaugmented 
airplane. The same flight case data were then used in the. RDFCS facility 
simulation. Next, the non- realtime simulation time history responses were 
used to check the RDFCS simulation. 


4.3.1 Airplane Simulations 

Both the non-realtime and the RDFCS simulations were implemented using a 
state variable approach as depicted in Figure 13. Here the pitch-axis 
dynamics of the free RSS airplane, as captured in the matrix A, are quite 
divergent or unstable, so certain states must be fed back to enable a 
stability augmentation function. The state variables here are pitch, 
pitch rate, vertical axis velocity, and horizontal axis velocity. The 
first two states are inertially oriented, and are directly measured by 
airplane sensors. The second two are referenced to the airstream incident 
on the airplane, and are combined to form the directly measured signals, 
angle-of -attack and true airspeed. These two air data signals are 
produced using matrix C. 

The above sensor feedback signals then appear in vector u, and the 
pilots ' stick inputs are applied through vector d in Figure 13. No outer 
loop sensors as for autoland were used in this investigation, although 
they were included in the RDFCS simulation. 
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4. 3. 1.1 Flight Cases 


Table 7 summarizes conversions of six existing basic wide-body transport 
type flight cases to six corresponding RSS flight cases with -5% static 
stability margins. For Flight Case AlRSS for example, calculations 
revealed the neutral point to be at 53% of the mean aerodynamic chord 
(MAC) , where neutrality denotes no pitch moment change with a change in 
angle - of - at tack . More specifically, the stability derivative describing 
the airframe behavior goes to zero. The -5% static margin then 
corresponds to shifting the center-of -gravity aft to 58% MAC. 

This type of alteration to the airframe dynamics yields a pa:'r of real or 
non-oscillatory roots, M Tau 1" and n Tau 2" in Table 7. Note that the 
negative time constants for Tau 2 correspond to positive roots, which 
plot on the positive axis of the s-plane, produce an absolute; instability 
or exponential divergence that dominates the dynamic response of the 
airplane's pitch-axis. With a negative 5% margin, moreover : the rate of 
divergence is rather rapid, and this is clearly unacceptable For Flight 
Case F6RSS , for example, the 3.17 second time constant yields a doubling 
of pitch attitude in 2.2 seconds, which is quite rapid and unflyable. 

Such a tendency must be overcome by a stability augmentation function 
whose closed- loop eigenvalues rectify these kinds of dynamic responses. 
Note that instability per se is not necessarily unacceptable for four of 
the basic flight cases exhibit a negatively damped phugoid. In all 
cases, however, the negative damping is quite small and the phugoid 
period is relatively long. 


4. 3. 1.2 Simulation Organization 

A non-realtime simulation was used to generate airplane time history 
check cases prior to work at the RDFCS simulator. The organization of 
the airplane simulation was actually the same as that of the one which 
had previously been installed in the PDP-11/60 at NASA Ames. For the RSS 
flight cases, no changes were made to the software organization itself, 
however, other than to add interfaces for the SAS control laws. 
Basically, the organization of the simulation provides for the conversion 
of flight case data into a discre te - t ime model, trimming for specified 
initial conditions, and the generation of dynamic time history outputs. 
Ground effects, random gust options, or point simulation flight case 
transitions may be selected. 


34 



JRiGiWAL PAGE (3 

OF POOR QUALITY 


Table 7. Relaxed Static Stability Flight Cases 


r LIGHT 

:ase 

CENTER 

OF 

GRAVITY 
% c 

NEUTRAL 
POINT 
% "c 

V T 

fps 

T 1 

sec 

T 2 

sec 

^PH 

rad/sec 

^ PH 

- 

AC m 

A5 h 

1/rad 

ac m 

Aq 

1 /rir* 
*•/ ^ - 

AC^ 

A<x 

--c/rad 

AC?o[ i 
AC L : 

- i 

r— 

AC^ 

Aoc 

1/rad 

AlRSS 

58.0 

53.0 

283.7 

1.099 

-5.86 

0.169 

0.276 

-3.247 

-11.48 

-3.14 

0.050 
— — 

0.295 


51.0 

46.0 

— 

910.7 

0.160 

-2.40 

0.008 

0.325 

-2.830 

-14. 

-7.83 

0.044 ! 

0.353 

j C13RSS 
C15RSS 

54.2 

49.2 

442.2 

0.122 

-1.64 

0.134 

0.526 

-2.415 

■-12.I5 

,.t . . 

-3.44 

0.053 

0.288 

D2RSS 

52.8 

47.8 

487.1 

0.660 

-7.55 

0.125 

0.453 

-2.533 

; - 12 . 75 
1 — 

-3.18 

0.050 

0.292 

E3RSS 

55.5 

47.8 

265.7 

0.938 

-7.09 

0.167 

0.488 

-3.138 

1-11.76 
0- 

-3.14 

0.053 

0.306 

F6RSS 

64.4 

49.4 

224. 1 

0.920 

-3.17 

0.209 

0.192 

-3.016 

1-11.23 
J 

-3.03 

0.170 

0.960 


4.3.2 Flight Case Analyses 


Two stages of analysis were performed. First, the RSS airplane behavior 
was approximated by aft shifting of the center- of - gravity to -5% MAC. 
Note that six old flight cases have been converted into six derivatives 
sensitive to the reduced lever arm of the empennage aboi t the new center 
of gravity ere appropriately changed. As indicated in Tcble 7, these all 
relate to the generation of pitching moment. The am lysis of the RSS 
flight cases then involved the examination of their respective dynamics. 
Specifically, the RSS stability derivatives ere used to calculate the 
free airplane response by finding the root solutions to the 
characteristic equation for each flight case. These results also are 
given in Table 7. 

Basically, defining a RSS flight case involves finding the neutral point 
center-of- gravity , i.e., the point at which no pitching moment results 

from a lift change on the wing. This point, in terms of percent of the 

mean aerodynamic chord (MAC) , is therefore found to be 53% for Flight 
Case AlRSS. Since a -5% stability margin is desired, the center-of- 
gravity for Flight AlRSS 58%. The shortened lever arm from the horizontal 
stabilizer to the center-of -gravity produces a proportionate reduction in 
moment generating capability, as evident in certain of the RSS stability 
derivatives given in Table 7. 

Note that the sign on pitching moment due to wing lift changes from 
"minus" for 25% to "plus” for 58%. In the RSS case then Increasing lift 

produces more nose up moment, which in turn increases lift further. This 

positive feedback effect constitutes unconditional Instability in the 
free or unaugmented airplane response. The rate of divergence is quite 
rapid. For Flight Case F6RSS, for example, the time constant of -3.17 
seconds yields a doubling of pitch attitude every 2.2 seconds. The given 
time constants, radial frequencies, and damping ratios were obtained from 
the root solutions of the characteristic equations for the respective 
flight cases, as determined by the stability derivatives 
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4. 3. 2.1 Simulation Check Cases 


Simulation check cases were first run c-'rig ’^^"’"case^and checked 
simulation . Time histories were ^™ra ed for ^ ^ 

against the root solutions. For the RSS “ le sequence exhibits 
dominated the time histories. ' h ' t L L analytical 

an exponential time constant sec onds for Flight Case F6RSS 

calculated time constant va , initial upset employed here 

once the initial transient has -balded. ^hLit the 

iLJahiH?”‘R^r ifio -d r as a standard upset as needed for the 
corresponding augmented airplane . 

While these free airplane responses are ^ ^Le^esponsf if used'to 

real-time airplane simulation the a ”^ 1 gmentation control laws, 

check both the simulation and the stability a g ^ „ ade £or the 

Analytical root solution (eigenvalue) check characteristic 

augmented airplane response *" o£ 1he se „ solrs feedbocks . AH 

equations is increased due to the presen _ and they serve to 

corroborate the\ontrol law done in different stages of development. 


4. 3. 2. 2 Stability Augmentation Requirements 

in general, the requirement! s for 

desirable flying qualities f R 8 hould exh ? b it suitable damping 

eigenvalues of the closed-loop Sh ° the augmentat i„„ control law 

and frequency characteristics . In^ effect ^^t^ ^ 

increasin^wing lift. Restoration of the negative pitching moment IS 
possible through a nose-down stabilizer input for rncroasing angle-of- 

attack . 

For the subject demonstration the design S *” Rl ^ e 3 ° 0 ^° £or 

RSS be au e gm;„tS tCh airplane as waf availahie on the 
basic 25% MAC center-of -gravity free airplane. 
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4.4 RDFCS Facility Modifications 


Because of the scope and complexity of the RDFCS simulator, t 
to the facility were rather extensive. Converting a sin 
operational system to a double fail-operational one is cl 
™;/ nd alt °S e ther the details handled were quite apprec 
DFCS software, the airplane simulation, and the system inter 
were re-worked. Then the test software to evaluate' the AFBW s 
developed^ With respect to Figure 14, software changes or addi 
made to the FCCs , the MDICU, and the PDP-11/04. Some new pin a 
were made for the back connector breakout panel pins, and s 
switch functions were designated at the logic discrete panel. 


ne changes 
gle fail- 
early non- 
Lable . The 
connection 
/stem were 
cions were 
^signments 
everal new 


4.4.1 


Pitch-Axis Augmented Fly-by-Wire System 


Basically, an essentially new DFCS flight software load module was 
eveloped. A double fail-operational system architecture was implemented 
h computational frame synchronization across the four channels, 
coo] dinati on was accomplished using control variables broadcasted 
by each channel over existing serial digital buses. This involved new 
absolute address assignments during software linking. As a result the 
ATBW was implemented without any hardware modifications to the flight 
computers. Because of the relatively slow refresh rat- of the 

asynchronous digital buses, the frame synchronization process was much 

c^uJSSal^^- BUt thg ^ °^tion was not 


4.4. 1.1 Stability Augmentation Control Laws 


The control laws were 
with variable scaling 
in Figure 15. Only 
stick blending logic 
8 . ’ 


implemented using the customary Tustin transform 
to unity. The. details for any one channel appear 
the pilot's stick was connected, so there was no 
The voter/comparator thresholds are given in Table 


4. 4. 1.2 Augmented Airplane Check Cases 


I^thrpDp'n^n 0 "” ° f Fli «/. Case F6RSS the free airplane simulated 

th l A ll / bQ 15 Panted m Figure 16. An initial pitch rate upset 
is introduced, and the ensuing pitch axis divergence was found to conform 
^ "on-realtime check case time history. Noting the trace for pitch 
attitude excursions about trim, a time constant of about 3.0 seconds can 
be observed over seven one-second intervals averaged between 1 and 8 
seconds. This compares with the computed positive real root in Table 6 of 
3.17 seconds. All six RSS flight cases were checked out in this same 
manner, comparing time histories and calculating response time constants. 
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Figure 14. Palletized DFCS 


















Table 8. Sensor Comparator Thresholds 


MONITORED 

COMPARATOR 



VALIDITY FLAG 

SIGNAL 

AMPLITUDE THRESHOLD 

TIME DELAY 

TRIP DELAY 

HEALING DELAY 

Angle -of -Attack 

1.0 degrees 

250 ms 

1 . 0 sec 

2 . 0 sec 

Pilots' Stick Inputs 

5% full stick 

200 ms 

N/A 

N/A 

Pitch Rate 

0.5 deg/sec 

400 ms 

2 50 ms 

1 . 0 sec 

Stabilizer Command 

0.1 degrees 

100 ms 

100 ms 

100 ms 
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Figure 16. Free RSS Airplane Time History 
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4.4.2 


Augmented Fly-by-Wire Modifications 


Simulated interconnect wiring changes are noted in Tables 9 and 10. 
Sheet 1 of Table 9 summarizes how the simulation output was modified to 
provide the sensor signals needed for the SAS function. Sheet 2 shows 
how these signals were directed through the MDICU and into the FCCs . In 
all , three software programs had to be altered to effectuate these 
changes. Table 9 summarizes the discrete logic input signals and their 
routing into the FCCs. Note that FCC memory locations were chosen to be 
the same in each computer channel so that the software in each channel 
would be as well. 

Figure 17 indicates the top-level software flow in the FCCs. This 
encompasses and implements the previously verified software design. Note 
that several levels of control logic appear in a flow chart form here, 
but there remains a one-to-one correspondence with the design. The 
flight control laws were calculated in the Foreground segment. 

The closed- loop stability augmentation short-period response for Flight 
Case F6RSS is shown in Figure 18. The initial pitch rate is rather 
quickly damped out with only a small second overshoot. The augmentation 
command produces a smooth horizontal stabilizer input that vanishes in 5 
seconds. The phugoid for the augmented airplane is not evident in the 
brief time history, but there are no indications of significant looseness 
or divergence. Obviously, the flying qualities of the augmented airplane 
here are quite good, and in the case of the other RSS flight cases as 
well. This caliber of pitch axis response then serves as the reference to 
which flying qualities degradation is assessed during sensor failure 
effects testing. 
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Figure 17 . Software Control Flow Diagram 
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Figure 18. Augmented RSS Airplane Time History 
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4.5 Simulator Investigations 


The investigations performed on the AFBW system included: system- level 
failure effects testing that focused on flying qualities degradation and 
real-time, multilevel assessment of software behavior that focused on 
architectural fault tolerance. The former type testing was rather 
conventional, and as noted earlier, impeded by a low- fidelity pilot 
interface The latter was rather sophisticated, and is thought to 
constitute a valuable new testing methodology for system simulators. 


4.5.1 Investigation Test Plan 

The test plan focused on demonstrating multilevel testing as a means of 
obtaining higher confidence in the airworthiness of a DFCS . Table 10 
indicates five levels of testing undertaken. The to P eve ls 

conventional system or functional testing, as required here to examine 
RSS flying qualities. Four specific levels of the control structure were 
explored coincidentally. These were related to pnoi development 

activities as depicted in Figure 19. To accomplish this, there was 
appreciable emphasis on automated testing and wideband instrumentation. 
In all, these thrusts were seen as vital new ways of utilizing iron ir 
system simulators. 


Table 11. DFCS Testing Scenario 


TYPE OF 
JESTING 

— 

FOCUS 

— 

EXECUTION i 

MONITOR i 

i 

MONITOR 

LOCATION 

PRIMARY 

CONCERN 

SYSTEM 

SYSTEM 

1 

NONE 

N/A 

FAULTED FLYING 

VALIDATION 

PERFORMANCE 


- ■ 4 

QUALITIES 

SYSTEM 

SYSTEM 

NESTED FINITE- 

SIMULATION/ 

FAULTED 

VERIFICATION 

STATE 

STATE MACHINES 

TEST COMPUTER 

STATES 

■ 


CHANNEL 

PREDICATE/ 

SINGLE 

SINGLE-POINT 


SYNCHRONIZATION 

TRANSITION 

NETWORK 

CHANNEL 

| FAILURES 


— H 

MODE/FAULT 

BOOLEAN 

SINGLE 

LOGIC 


LOGIC 

EXPRESSIONS 

CHANNEL 

CORRECTNESS 


CONTROL 

CONTROL 

SINGLE 

PATH 


FLOW 

GRAPHS WITH 
ASSERTIONS 

CHANNEL 

TRAVERSALS 

i 
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Figure 19. Multilevel Testing Closure 













4.5.2 Test Execution Monitor 


Two test execution monitors were developed and demonstrated during the 
AFBW investigations. The scenario employed is represented in Figure 20. 
The successful use of these real-time execution monitors was a major 
accomplishment of this investigation. System state logic was observed by 
an execution monitor in the PDP-11/60, via an instrumentation link 
through the PDP-11/04. The execution monitor was basically a finite -state 
machine that was driven in parallel with the DFCS software by the same 
logic inputs. The monitor checked to see that the DFCS software and the 
PDP-11/60 software remained in accord with the design specified state of 
the system. 

The second execution monitor resided in one of the flight computers 
because of PDP-11/04 instrumentation bandwidth limitations. This monitor 
focused on the three-way channel synchronization process, under the 
assumption of the prior loss of the fourth processor. Specifically, the 
synchronization control signals for the other three channels were 
observed and compared with the nested state transition graphs of Figuie 
7. Note that this same form of test criteria was applicable to the 
predicate/transition network simulation described previously. This 
precise means of propagating accountability and ensuring consistency is 
considered a superior and quite practical way of fostering a quality 
DFCS. 



Figure 20. Automated Testing Scheme 
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4.5.3 


Simulator Testing 


Actual testing of the quadruplex DFCS included checkout, development, and 
demonstration tasks. System failure effects testing focused largely on 
flight computer failure to validate architectural fault tolerance, and 
sensor failure effects to validate graceful degradation of flying 
qualities. The conduct of multichannel synchronization was captured 
primarily in the time history form shown in Figure 21 , and on a more 
detailed level, by the real-time execution monitors. 

Each pulse in Figure 21 corresponds to a 50 millisecond computational 
frame, and the pulse amplitude denotes which of four foreground executive 
program control paths is being traversed. Here cross - channel frame and 
path synchronization is being maintained. Faults or transient disruptions 
were simulated by halting a processor at its CAPS test adapter panel, or 
by interrupting electrical power at the circuit breaker. Flying qualities 
degradation was observed by upon simulating multiple sensor faults for a 
given type of sensor, pitch rate or angle-of -attack . Sensors faults were 
applied through the MDICU or at the back connector breakout panel. 


4. 5. 3.1 Synchronization Failure Effects 

Figure 22 shows the slowed-down initial synchronization of three DFCS 
channels. At the outset, only Channel 3 is cycling in the foreground 
mode. Channel 2 then synchronizes, followed by Channel 1. Here Channel 4 
is being used to run a real-time execution monitor, so it cannot come on 
line. Other exercises involved drop-out and re- sync hronization as 
individual computer channels were halted and released. Re - synchronization 
always occurred within two cycles. 

By chance, an actual clock tolerance problem occurred in one DFCS channel 
during the early stages of testing, thereby causing frequent 
synchronization drop-out of the affected channel. At first, a DFCS 
software flaw was suspected, but it was eventually determined that the 
hardware was at fault. The re - synchronization software, moreover, was 
responding promptly and correctly. 
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During subsequent multiple computer channels shu d »n/re-, start , =-^6.^ 
re -synchronization discrepancy was "““^ Specif ground' executive paths 
getting two synchronized parrs on dLfferen 8 synchronized, 

Tt ST to°pa!rs “uld “ot'syn^nX'with each other. Representing the 
but the P m-edicate/ transit ion network simulation revealed 
same conditions m the P™ catena incomplet ely defined, and the 
the same problem, so the design nan d d i scern this . Probably, a 
design verification test cases a would have strengthened the 

simulation^had £ ^1“ characterize and resolve 
the problem seen in system simulation. 


4. 5, 3. 2 Sensor Failure Effects 

Sel^ontrLuoff^ *”°s“.bUu” 

— r V 1Y 

stabilizer input is noticeably less in F ^« ex ”„ ded _ The r Lult a less 

-^nse that constitutes^the^lying^a UtUs 

Sul“i 0 are°no? e unsa t f e Ple Fu«her “anllysU, and probably PU°t-in-th«- 
loop simulation would be needed to determine te have 

to^be^so^ evaluated » t2L% the ” 0 ^ case pi Jh rate sensor fault 
situation . 

Toss of all angle - of - attack sensor feedback is represented in the time 
history response in Figure 24. The flying qualities degradation here is 
v^ mucrTrse than that shown in Figure 23, as had been recognized in 
!he eallv stages of development and in the reliability analysis. Still, 
ngure 2 l reveals some degree of benefit resulting from the pitch rate 

feedback as contrasted with the free “rplane^response^in^lguie^lS^The 
horizontal '“h 1 ? 1 ’* 1 “ it „* divergence nonetheless occurs, 

^iflfrLe^nt^ler^te^an ^ pilo,in- 

Seg«datl» h«r“ d«med OC to PO be unadaptable and unsafe regarding the 
difficulty of manually flying such an airplane. 

Rote that the autopilot attitude hoMmode provides ^ck-up^pability 

for managing the pitch a. fl f rD lane as desired. A pitch command 

rnri e p“chia”“io! ^ •»»= 

knob 01 a pitch axis co extended flight. In such a situation, the 

may not be very accep tab lities must be carefully performed on 

assessment of safety and t y g q management strategy and 

a special case bases where he ^ in J the overall DFC S 

°d P e:r g : i0 ?hl a:i:.ss b m e ent approach, however is still employed, 

namely that of a phased, integrated assurance methodolog> . 
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5.0 CONCLUSIONS 


Although the thrust of this effort was directed more toward the 
adaptation and demonstration of assurance methods in a subsetted 
development process, certain findings did result. The following general 
conclusions were derived or confirmed through the work described in this 
report : 

o Digitally mechanized flight control systems are significantly more 
complex and difficult to validate than comparable analog systems 

o An integrated, assurance - driven development methodology is 

particularly vital for fault- tolerant DFCS architectures 

o Resultantly improved system/software structure greatly reduces the 
subject complexity, thereby facilitating validation 

o Good structure also eases the impact of development changes, and 
reduces the number of validation test cases 

o Automated multilevel testing can be effectively and beneficially 
performed in system simulators with modest additions 

o Wideband software instrumentation and real-time tost execution 
monitors are especially valuable additions for system simulator 
testing of critical DFCSs 

o Use of the same execution monitor test cases and criteria for 
early-on analytical simulation and for all-up system simulation 
greatly extends confidence in the assurance process 

o Multilevel test cases and criteria recapitulate and ultimately 
confirm the overall development process. 
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